Обновить

FAQ по Shadowsocks/XRay/XTLS/Reality/Nekobox/etc. для обхода блокировок

Уровень сложности Простой
Время на прочтение 17 мин
Количество просмотров 31K

Эта статья - сборник разных вопросов и ответов на них, которые звучали в комментариях к моим предыдущим статьям (Современные технологии обхода блокировок: V2Ray, XRay, XTLS, Hysteria, Cloak и все-все-всеBleeding-edge обход блокировок с полной маскировкой: настраиваем сервер и клиент XRay с XTLS-Reality быстро и просто и других из той же серии) и в личных сообщениях.

Традиционная нейрокартинка для отвлечения внимания
Традиционная нейрокартинка для отвлечения внимания

Разное

Пользуюсь прокси, и некоторые сервисы/приложения каким-то образом определяют, что я сижу через прокси, как они это делают?

Классических способов выявить прокси/VPN не так много, самые известные:

1) разница между часовыми поясами у клиента в браузере и в локации IP-адреса с которого он подключается (например, в браузере московский часовой пояс, а сервер в Лондоне и там пояс другой) - обойти элементарно;

2) выявление по MTU - ненадежно, актуально для OpenVPN/L2TP/Wireguard/SSTP, для XRay и подобных прокси не актуально, т.к. они работают на другом уровне;

3) сканирование IP клиента на предмет открытых стандартных портов (например, 443) - можно обойти цепочкой из двух серверов с туннелем между ними;

Если вы используете мобильное устройство, то банковское (или любое другое приложение) может смотреть, активен ли в системе VPN-интерфейс, либо сравнивать геолокацию устройства и локацию по IP-адресу. Некоторые особо тупые российские сервисы по умолчанию считают что "любой доступ из-за рубежа - значит включен VPN". И еще некоторые сервисы (типа Open AI) по умолчанию запрещают доступ с non-residental IP-адресов (то есть 99.9% VPS-хостеров).

Я настраиваю сервер с XTLS-Reality, как это сделать максимально правильно?

Суть Reality в маскировке под какой-либо популярный сайт, поэтому когда вы решаете это делать, вам нужно добиться того, чтобы ваш IP (IP вашего VPS) вел себя полностью идентично настоящему серверу, которым вы прикидываетесь. Если тот "настоящий" сервер слушает на 80-м порту (plain HTTP), то вам тоже нужно настроить nginx или правило фаервола, чтобы переадресовывать HTTP-запросы на оригинальный сервер. Если "настоящий" сервер не слушает SSH-подключения на стандартном 22-м порту, то ваш тоже не должен. Если ваш хостер предоставляет reverse-DNS записи для IP-адреса, убедитесь, что там не осталось значение по умолчанию (обычно с доменом хостера), а лучше задайте такой reverse-DNS, какой виден у IP-адреса ресурса, под который вы маскируетесь.

А почему рекомендуют избегать посещения через прокси зоны RU?

По закону Яровой у нас давно уже пишутся все метаданные интернет-активности (куда, когда, откуда были подключения, какие объемы данных передавались, и т.д.). В теории (но судя по тому, насколько часто встречается эти совет на китайских сайтах, у них это уже не в теории) возможно следующее: вы случайно (даже просто зайдя на какой-нибудь обычный сайт, который подгрузит скрипту или контент с другого сервера) через свой прокси делаете запрос на условный Яндекс/Мейл/ВК/Госуслуги. В логах метаданных видно: подключение от вас на какой-то внешний IP, и точно в тот же самый момент подключение с этого IP к сервису внутри страны (который, понятное дело, тоже подконтрольный), объемы переданных данных одинаковы (с учётом оверхеда протокола) - и после ряда таких совпадений можно однозначно сказать что на этом адресе работает прокси.

Либо ещё вариант: вы подключаетесь к сервису, сервис в ответ сканирует популярные порты IP-адреса с которого вы пришли, и видит там открытый 443 порт - тоже очень подозрительно, весьма вероятно что прокси, можно банить. Поэтому варианта два: или делать цепочку из двух прокси-серверов или один сервер с двумя разными адресами (сопоставить будет многократно сложнее), или создавать правила чтобы трафик от клиента до местных сайтов шел напрямую, а на прокси-сервере для надёжности резался.

Ну или мобильное приложение у вас на телефоне (имеющее доступ к геолокация или имени активной сотовой сети) видит что вы вроде внутри страны, но при этом подключение к их серверу происходит с какого-то иностранного адреса - тоже опачки :)

Что новенького появилось с момента обзора прокси-клиентов?

У Nekobox появилась русская локализация, а также в качестве ядра, помимо sing-box, там теперь можно использовать xray вместо безнадежно устаревшего v2ray.

Под Windows, macOS, Linux и Android появился многообещающий клиент Hiddify-Next, написанный на Flutter и основанный на Sing-box - у него очень простой интерфейс, работает хорошо, умеет автоматически пропускать напрямую трафик до ресурсов выбранной страны (Россия в списке тоже есть), не требуя дополнительной настройки маршрутов, поддерживает и прокси- и TUN-режимы, а ещё при получении списка серверов под подписке может пинговать их всех и автоматически использовать тот, который отвечает лучше всего. Название у него совпадает с названием известной панели, но по факту он может работать с любыми совместимыми серверами.

Под iOS появился новый клиент Streisand - я не пробовал, кто уже пользовался, расскажите, как оно.

А ещё новости из мира протоколов - вышла новая версия протокола Hysteria - Hysteria2. В Sing-box уже поддерживается.

Как цензоры умудряются заблокировать Shadowsocks даже версии 2022?

Согласно последнему GFW Report, детектировать Shadowsocks-2022 не умеют до сих пор даже китайцы, в итоге они просто в период обострений банят все протоколы, которые (не опознаны на DPI) AND (не похожи на простые текстовые).

В итоге получается прибить SS-соединения, пусть и ценой огромного collateral damage (побочных эффектов) - блокируются все неопознанные протоколы, то есть по сути дела мы имеем дело с белыми списками.

Кроме того, как заметили пользователи ntc.party "У SS есть одна особенность, запросы к серверу не мультиплексируются. Можно считать число подключений к паре адрес:порт и блокировать при превышении лимитов. Синтетические тесты такую блокировку не выявят. Например, при открытии браузером youtube, число установленных подключений к SS достигает 18, сам браузер открывает максимум 12 (числа взяты из эксперимента и могут отличаться)." Вывод - при работе через SS включайте мультиплексирование в клиенте. Клиент и сервер для этого должны быть одинаковые, потому что у XRay и Sing-box разные, не совместимые между собой механизмы мультиплексирования.

У меня на сервере был OpenVPN/Wireguard, после начала протокольных блокировок я установил XRay, и все равно ничего не работает

Есть свидетельства о том, что РКН в некоторых случаях банит сервера целиком по IP, если до этого на них были зафиксированы подключения по детектируемым VPN-протоколам.
Решение только одно - пересоздавать сервер, чтобы был новый IP-адрес.

Правда ли что VLESS не использует шифрование, и поэтому использовать его небезопасно для конфиденциальных данных.

Нет. То, что VLESS не предусматривает шифрования на уровне протокола, не значит, что данные передаются в нешифрованном виде. VLESS всегда работает поверх TLS, трафик шифруется именно механизмами TLS, а не самого VLESS. Никакой проблемы с безопасностью тут нет, все секьюрно :)

То же самое с XTLS. XTLS отключает свой слой шифрования только в случае, если определяет, что обмен между пользователем и конечным сервером уже зашифрован TLS v1.3.

Нет ли какого-нибудь решения с VLESS, что бы завести к примеру 3х пользователей, но не пускать их в интернет, а раздать им доступы в разные внутренние сетки на контурах? Кажется 3Х-UI и подобные панели не умеют в разные приватные сети пользователей направлять.

3X-UI такое вроде не умеет, а голый XRay кажется настроить можно.
Сделать настройки Routing в конфиге, и в зависимости от ID пользователя, если destination IP совпадает с адресом разрешенной ему сети, то отправлять на соответствующий outbound'ы для этой сети, а все остальные запросы отправлять в block.
и в outbound'ах можно задать опцию sendthrough (https://xtls.github.io/en/config/outbound.html#outboundobject), чтобы трафик шел через правильный интерфейс.

Задержки 1100-1800 ms для Нидерландского сервера это норм для XTLS-Reality? Скорость не падает.

Да, норм. Два важных отличия от других технологий: 1) в отличие от VPN, где подключение к VPN-серверу устанавливается один раз и все, в случае с прокси, на каждое исходящее подключение из клиентского софта устанавливается новое подключение к прокси-серверу (если только не используется мультиплексирование) 2) поскольку через прокси невозможно послать ICMP-пинг, большинство клиентов меряют задержку не пингом, а выполнением HTTP-запроса.

Вот и считайте: когда вы запускаете тест, сначала устанавливается TCP-соединение с прокси-сервером (уже как минимум один, а то и два round-trip). Потом поверх него происходит TLS-хендшейк (ещё один round-trip), и в процессе него прокси-сервер ещё устанавливает TCP-соединение с reality-dest сервером и запрашивает у него сертификат. Потом прокси посылает запрос на установление TCP-соединения с тем сервером, который используется для теста. Потом, если URL указан как HTTPS, происходит ещё TLS-хендшейк с ним. Потом клиент делает HTTP-запрос и ждёт получения ответа. И только после ответа вы видите результат теста, и "задержка" - это суммарное время всего вышеописанного процесса.

Совет от@quakin:

Есть способ существенно уменьшить задержки для VLESS-Reality: маскироваться под сайт, пинг до которого от VPS минимальный.

Более продвинутый способ: использовать утилиту от авторов XTLS для выбора маскировочного сайта из той же подсети: RealiTLScanner.

Можно ли самого XRay/Sing-box завернуть подключения в корпоративный прокси для обхода ограничений интернета в организации? 

Можно ли настроить подключение через пару прокси-серверов?

XRay и Sing-box умеют делать цепочки прокси.
В Sing-box, например, можно для каждого outbound'а задать "detour" (другой прокси), и таким образом достучаться до своего VLESS или Shadowsocks-сервера через корпоративный HTTP/SOCKS прокси. Если вы используете Nekobox,  то нужно создать в Nekobox одно подключение типа HTTP или SOCKS (для корпоративного прокси с его адресом). Потом создать отдельно ещё одно подключение, VLESS для вашего сервера.
И потом создать третье подключение типа Proxy Chain, и в него добавить первые два в нужном порядке.
Если корпоративный прокси суровый (перешифровывает TLS с подменой сертификатов), то чистый VLESS скорее всего не пропустит, но вполне может работать вариант с websocket-транспортом.

Что такое port-hopping?

Пользователи из Китая писали, что когда GFW банит подключения к их прокси-серверу, ограничения часто применяются только к конкретному используемому порту. В качестве обходного пути в этой ситуации можно использовать port hopping, когда прокси-сервер слушает сразу на сотнях портов, и подключаться можно к любому - это может быть очень полезно при использовании Shadowsocks.

Сделать это можно с помощью iptables DNAT:

iptables -t nat -A PREROUTING -i eth0 -p udp --dport 20000:50000 -j DNAT --to-destination :555
ip6tables -t nat -A PREROUTING -i eth0 -p udp --dport 20000:50000 -j DNAT --to-destination :555

В этом примере сервер слушает порт 555, но клиент может подключиться к любому порту в диапазоне 20000–50000.

Как понять, что у меня используется именно Shadowsocks-2022, а не старый классический Shadowsocks с уязвимостями?

В конфигурации клиента и сервера нужно использовать method который начинается с "2022-", например 2022-blake3-aes-128-gcm и 2022-blake3-aes-256-gcm (это стандартные), или 2022-blake3-chacha20-poly1305, 2022-blake3-chacha12-poly1305, 2022-blake3-chacha8-poly1305 (это extra).

Для меня стало большим откровением, что современные браузеры при использовании любых прокси или VPN сливают ваш IP адрес через WebRTC

Используйте TUN-режим в клиенте.

Что такое "steal from yourself"?

Это когда вы используете Reality, но прикрываясь своим же доменом. По сравнению с Reality - быстрее устанавливается соединение, вы не зависимости от чужого сервера (который может отключить TLS1.3 по техническим причинам, или может забанить коннекты с IP вашего VPS, если вы его достанете), полная аутентичность (не надо маскироваться до каждой детали). По сравнению со схемой без Reality, а просто с VLESS и fallback'ом - у вашего сервера будет TLS-fingerprint как у настоящего веб-сервера (например, Nginx).

Настраивается просто: например, XRay слушает на 443 порту с Reality, в качестве "dest" у него указан "127.0.0.1:8443",а Nginx со своим сайтом с настроенным TLS слушает на 127.0.0.1 и порту 8443.

Это все слишком сложно, можно как-то попроще?

Если все это слишком сложно - то советую Amnezia VPN, он устанавливается на любой сервер двумя кликами в понятном интерфейсе, есть клиенты под все платформы, и они тоже активно работают над защитой от выявления и блокирования.
Ну либо перемещать себя в юрисдикцию, где нет блокировок по протоколам.

К чему еще стоит присмотреться кроме XRay и Sing-box?

Hysteria.

Настройка маршрутизации и клиентов

Как настроить, чтобы на российские сервера и сайты доступ шел напрямую, без прокси?

Shadowrocket на iOS

На главном экране в пункте Global routing выбираем Config:

Далее идем на вкладку Config, там идем в General:

Скроллим ниже к Skip Proxy, и добавляем туда новый пункт "*.ru":

Сохраняем. Всё, готово.

Если нужен еще GeoIP, то чуть сложнее.

Идем на MaxMind Geolite2 и регистрируемся там: https://dev.maxmind.com/geoip/geolite2-free-geolocation-data

Как зарегались и залогинились - нажимаем Manage License Keys -> Create License Key. Он сгенерит новую лицензию - важно сразу сохранить Account ID и License Key, ключ целиком показывается в интерфейсе только один раз, потом еще раз посмотреть уже нельзя будет!

В Shadowrocket идем в Settings, там ищем Geolite2, и заполняем наши данные:

Нажимаем Update - он должен подтянуть актуальную базу.

Потом как и в прошлом пункте, на главном экране выбираем Global Routing - Config, идем в Config, и там не в General, а в Rules:

Жмем плюсик, и создаем новое правило с типом geoip, policy = direct, и country/area пишем "RU" (обязательно большим буквами, иначе не сработает):

Сохраняем, пользуемся.

Nekobox на Windows/Linux/MacOS

GeoIP активируется стандартным образом в Nekobox (не забудьте поставить sniffing mode в "used for routing!"):

Правила по суффиксам Nekobox не умеет, но их умеет sing-box в его основе, поэтому жмем "Custom" и прописываем

вот такое
{
    "rules": [
        {
            "domain_suffix": [
                ".ru"
            ],
            "outbound": "direct"
        }
    ]
}

После этого весь трафик до .ru-доменов и российских IP-адресов будет идти напрямую.

Если нужно заблокировать полностью - то в первом окне вместо Direct вставить в Block, а в JSON-коде исправить direct на block.

Nekobox Android

В Nekobox Android достаточно всего пару правил (раздельных, не два условия в одном правиле!), одного для доменов, другого для group.

И не забыть проверить, что в настройках включен sniffing:

Wings X / FoxRay iOS

Можно использовать только category-ru-gov , либол наоборот, не использовать ее, а прописать правила для всех .ru-доменов и российских IP как ниже

v2rayN Android

и в Custom rules вписать вот такое:

возможно вариант с доменом может привести к ложным срабатываниям для адресов типа www.rust.org, тогда можно оставить только geoip, для большинства случаев этого будет достаточно.

Не могу зарегистрировать на MaxMind чтобы использовать GeoIP базы в Shadowrocket

Да, они не разрешают регистрации из России и с адресов VPS. Попросите кого-нибудь из знакомых из других стран зарегистрироваться за вас с вашим емайл-адресом или пошарить аккаунт, скачиваться должно без проблем.

Как добавлять в правила маршрутизации с кириллическими доменами? Не работает.

Используйте любой онлайновый punicode-конвертер, чтобы преобразовать их в адреса латиницей. Например, "мвд.рф" будет "xn--b1aew.xn--p1ai"

Можно ли автоматически использовать в прокси-клиенте списки "Антизапрета"?

Можно, ага. Качаете geoip.db и geosite.db вот отсюда: https://github.com/L11R/antizapret-sing-box-geo
И подсовываете их в ваш клиент. После этого настраиваете маршрутизацию как обычно, например, в качестве дефолтного маршрута выбираете bypass (direct), а через прокси пускаете IP-адреса по тегу geoip:antizapret и домены по тегуgeosites:antizapret

Также есть очень интересные списки на https://github.com/v2fly/domain-list-community

Столкнулся с проблемой, что проксируется только трафик браузера, трафик терминала, например, идёт мимо прокси

Это зависит от режима работы клиента.
В режиме system proxy устанавливается системный параметр, а вот использовать его или нет, зависит уже от самого приложения — браузеры его используют, а некоторые программы вообще не умеют и не хотят.
В режиме TUN заворачивается весь системный трафик, можно попробовать с ним, должно помочь.

Настроил правила роутинга в клиенте, но они, кажется, не работают - трафик все равно идет или весь напрямую, или весь на прокси, смотря что указано по умолчанию.

Надо смотреть настройки сниффинга в клиенте — во-первых он должен быть включен, и не AsIs, а что-то типа "Sniff for routing" или "Resolve Destination" (в зависимости от клиента):

Все включено, но роутинг все равно не работает как надо. Конфиг писал вручную.

У XRay есть специфика, там если заданы условия, по которым будет применять тот или иной роут (например, айпи назначения из такой-то подсети, inbound такой-то, протокол такой-то), то он применит этот роут только если все условия будут выполнены.
Ну и правила применяются сверху вниз, то есть первое правило которое полностью совпало, оно и будет использоваться

Я не использую никакие правила роутинга, но некоторые сайты все равно определяют мою реальную локацию, а не локацию прокси-сервера!

Если используется TUN-режим, в клиенте не включен IPv6 (на сервере - не важно), и при этом IPv6 предоставляется вашим провайдером - есть вероятность, что трафик до IPv4-ресурсов будет идти через прокси, а до IPv6-ресурсов - напрямую.

Это не проблема конкретно V2Ray/Xray/SS, это будет для любых прокси/VPN, работающих через TUN. Решение: включить IPv6 в клиенте (даже если сервер не поддерживает), либо отключить IPv6 на сетевом устройстве (LAN или WiFi).

На Гитхабе больше нет билдов Nekoray под MacOS :(

Есть неофициальные билды под мак:
https://github.com/aaaamirabbas/nekoray-macos/releases

Какие из прокси/VPN можно установить не имея прав администратора в Windows?

Большинство что консольных, что GUI клиентов Shadowsocks/Trojan/VLESS не требуют установки (достаточно кинуть файлы в папочку и запустить) и не требуют административного доступа. Но есть один нюанс: не получится работать через TUN-интерфейс (для установки драйвера и настройки сети нужны админские права), только через локальный прокси. Настройки прокси в винде, насколько я помню, может менять даже непривелигированный пользователь, и даже если админы запретили это делать, можно использовать браузер который не завязывается на системные настройки (например, Firefox точно так умеет).

Проблемы, ошибки, диагностика

С включенныи прокси не работают аудио-видео-звонки в месседжерах и онлайн-игры

Аудио- и видео- звонки, как и большинство игр, обычно используют передачу данных по UDP. VLESS/VMess/Shadowsocks поддерживают UDP, но у них есть проблемы с сохранением номера порта при реализации NAT, в результате чего могут быть проблемы. Для решения этих проблем разрабочики XRay придумали XUDP - специальное расширение протоколо, которое даст вам полноценный Full Cone NAT.

Как сделать, чтобы оно работало:
Если у вас и клиент и сервер на базе XRay свежих версий (1.8.3 и новее), то все должно работать автоматически.
Если у вас клиент на базе Sing-box (например, Nekobox), то надо явно в настройках подключения выбрать XUDP в параметре "Packet encoding".
Если у вас клиент на базе XRay, а сервер на базе Sing-box, то есть риск что ничего работать не будет, нужно менять клиент или сервер.

Клиент FoxRay на iPhone периодически вылетает, что делать?

В настройках FoxRay в меню Toolbox есть опция "reduce memory usage", возможно поможет.

Почему у клиентов теперь все предложения на YouTube, в браузере тоже хоть сбрасывай все настройки, показывает Тегеран. WTF?

Это загадка черной дыры, над которой мы долго ломали голову и так полностью и не разгадали.
У XRay совершенно точно трафик не прогоняется через какие-либо сервера ни в Иране, ни где-либо еще - это не то чтобы даже невозможно, но точно бессмысленно технически. В коде XRay ничего подобного нет.
Было подозрение что автор панели добавил в XRay какую-то отсебятину - проверили, в docker-образе оно собирается из исходников с гита, там никаких подозрительных патчей нет, и потом еще кто-то в комментариях к одной из старых статей пожаловался на такое же, только не про Иран, а про Китай :)
Для уверенности мы довольно долго смотрели в netstat и wireshark, вердикт - никаких левых подключений не делается.
Была теория, что возможно где-то в коде или конфигах захардкожены какие-нибудь региональные DNS-сервера (региональный сервер, резовля условный гугл и ютуб, может отдать его же адреса региональных зеркал и гугл с ютубом подумают, что вы оттуда) - опять же, в коде и конфигах ничего такого не нашлось.

Но есть еще одна теория.  Nekobox (возможно другие клиенты тоже, не проверял) в качестве "внутреннего" IPv6 адреса использует адрес из такого зарезервированного диапазона (ULA), где они должны генерироваться рандомно, и вероятность совпадения двух рандомных адресов ничтожна. То есть такой адрес должен быть уникальным, но в Nekobox он наоборот захардкожен один для всех случаев, и в итоге некоторые сервисы, которые могут каким-то образом получать и анализировать локальные адреса клиентов (например, Google с его телеметрией в Chrome и в Android), считают всех клиентов с таким внутренним адресом... одним и тем же клиентом, после чего сопоставляют их то ли с геолокацией, то ли с другими внутренними адресами, то ли и с тем и с тем, и в итоге в ряде случаев все пользователи Nekobox (и возможно других клиентов) для Гугла выглядят как пользователи откуда-то из Ирана, Китая или Азербайджана, вплоть до того, что со временем Гугл начинает считать публичный адрес прокси-сервера тоже иранским/китайским/etc, и это приводит к довольно забавным эффектам.

Варианты решения: не использовать TUN-режим (он же VPN mode), либо в правилах маршрутизации клиента или сервера запретить доступ до Google по IPv6, либо пропатчить клиент чтобы он использовал какой-нибудь другой внутренний адрес.

У меня FoXray не читает QR код (Shadowsocks-2022), пишет не корректные настройки. В то время этот же QR залетает в V2Box на ура. В чем может быть проблема, что я упустил? 

Если пытаетесь сканировать QR из X-UI панели — можно попробовать сначала добавить подключение оттуда по ссылке в локальный Nekoray, а уже оттуда пошарить QR. Ну и проверить, что в названии конфига и параметрах нет никаких лишних символов (кириллицы, амперсантов, вопросов, точек, лишних слешей, и т.д.)

Я в настройках клиента указал свой днс сервер на adguard home. В итоге у меня на сайтах проверки dnsleaktest.com светятся помимо моих днс резолверов еще и гугловские откуда-то…

Проверьте, что у вас в /etc/resolv.conf :)

Настраиваю Shadowsocks, при старте клиента или сервера ругается "illegal base64 data at input byte 3"

Что-то не то с ключом. Можно еще раз перегенерировать в панели (если используете панель), или с 'openssl rand -base64 16' или 'openssl rand -base64 32' (в зависимости от длины используемого шифра).

Пытаюсь запустить сервер, при запуске ругается "Failed to start: app/proxyman/inbound: failed to listen TCP on 443 > transport/internet: failed to listen on address: 0.0.0.0:443 > transport/internet/tcp: failed to listen TCP on 0.0.0.0:443 > listen tcp 0.0.0.0:443: bind: address already in use"

Ну ошибка говорит сама за себя: "address already in use" = на сервере на 443 порту запущен уже какой-то другой процесс. Можно посмотреть командой 'netstat -nlp' от рута, она покажет, какой процесс слушает какой порт.

Делаю netstat -nlp, и судя по всему, прокся слушает только на IPv6, чзх?

В линуксе выхлоп нетстата типа "tcp6 :::2323" обычно означает что сокет доступен и по IPv6, и по IPv4.
 

Пытаюсь запустить Nekoray под Windows, ругается на какие-то ошибки в библиотеках Qt

Если у вас старая версия Windows, то нужно использовать старые версии Nekoray — в новых уже нет поддержки Windows 7 (и Windows 8 кажется тоже).
Последняя такая версия — 3.17, файл называется "nekoray-3.17-2023-08-17-windows7-x64.zip".

Как точно определить, почему у меня клиент не подключается к серверу?

Увы, никак. В 99% случаев когда что-то не контачится, это будет какое-то несоответствие конфигурации между клиентом и сервером. Сам протокол сделан так, чтобы быть максимально недетектируемым, поэтому если серверу что-то не нравится (например, не совпал ключ пользователя, или еще что), то в ответ он не пришлет никаких ошибок чтобы не демаскировать себя, а будет молчать или рвать соединение - и остается только угадывать по логам.

Сделал все по инструкции, на сервере запустилась без ошибок, но прокси не работает. Nekobox говорит: "No connection could be made because the target machine actively refused it"

Ну собственно клиент говорит как есть — он не может подключиться к серверу. Либо на сервере не запущен процесс, либо фаервол на сервере блокирует подключения, либо фаервол на клиенте блокирует подключения, либо что-то не то с настройками.

Начать расследование можно с команды "netstat -nlp", которая покажет, действительно ли ваш прокси-сервер слушает входящие подключения, на каком именно IP и на каком порту.
Плюс проверьте конфигурацию фаервола согласно инструкциям для вашего дистрибутива, у некоторых дистрибутивов/хостеров по умолчанию есть правила, закрывающие все порты кроме явно разрешенных.

Также убедитесь, что вам не мешает локальный антивирус и его фаервол (например, некоторые жаловались на проблемы при наличии Касперского на клиентской машине).

В клиенте видны вот такие ошибки:

Похоже на протухшие системные корневые сертификаты из-за очень старой ОС без обновлений. Как вариант - попробовать поменять remote DNS в клиенте с https://8.8.8.8 на просто 8.8.8.8 или 1.1.1.1 (без https).

В NekoBox 3.18 на Macos режиме sing-box не активируется Tun Mode

https://github.com/abbasnaqdi/nekoray-macos/issues/36 -> 'sudo /Applications/nekoray_arm64.app/Contents/MacOS/nekoray'

На Android подписки заработали с v2rayNG, а с FoxRay на iOS нет

Без SSL-сертфиката и https-ссылки на подписку ничего не будет работать на iOS.

У меня сервер с XTLS-Vision или XTLS-Reality, при подключении с десктопа все работает, с мобильного устройства - нет, в чем может быть дело?

Проверьте настройки uTLS. Почему-то у многих клиентов при установке uTLS как "android" подключение фейлится, при установке uTLS как "chrome" - все работает. Не совсем понятно, это баг на стороне клиента или сервера, но баг интересный.

Использую Shadowsocks/Trojan/VLESS, и что-то скорость совсем не радует...

Настройте BBR на сервере, станет гораздо веселее:

echo "net.core.default_qdisc=fq" >> /etc/sysctl.conf
echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf
sysctl -p

либо более полный вариант тюнинга

net.core.rmem_max = 67108864
net.core.wmem_max = 67108864
net.core.netdev_max_backlog = 10000
net.core.somaxconn = 4096
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_keepalive_time = 1200
net.ipv4.tcp_keepalive_probes = 5
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.tcp_max_tw_buckets = 5000
net.ipv4.tcp_fastopen = 3
net.ipv4.tcp_mem = 25600 51200 102400
net.ipv4.udp_mem = 25600 51200 102400
net.ipv4.tcp_rmem = 4096 87380 67108864
net.ipv4.tcp_wmem = 4096 65536 67108864
net.ipv4.tcp_mtu_probing = 1
net.ipv4.tcp_slow_start_after_idle=0

На некоторых системах модуль bbr может быть не загружен по умолчанию, если

# sysctl net.ipv4.tcp_available_congestion_control
не выдает в списке bbr:
net.ipv4.tcp_available_congestion_control = reno cubic hybla vegas yeah
необходимо добавить и ребутнуться:
echo “tcp_bbr” > /etc/modules‑load.d/modules.conf

При использовании SS/VLESS периодически перестает работать Google, выдает "That’s an error.Your client does not have permission to get URL / from this server. That’s all we know."

Это известная проблема со стороны Гугла при доступе с некоторых VPS по IPv6. Стоит попробовать отключить IPv6 в клиенте, если включен (обычно в настройках TUN-режима, если используете его), также в настройках DNS/роутинга выбрать PreferIPv4 если есть такая опция. Если ничего не помогает, то последний метод - если используете TUN-режим, то попробовать обычный прокси-режим, и наоборот.

Панели

Забыл логин или пароль 3X-UI, как восстановить?

Если подключен телеграм бот, то можно сделать бэкап конфига и бд, открываем .db файл блокнотом и ищем возможные части комбинаций пароля или логина.

Как обновить X-UI? Устанавливал через Docker

A: 1) Зайти в папку cd x-ui; 2) Потом остановить контейнер: 'docker-compose down' 3) Обновить, 'docker-compose pull xui'; 4) И запустить обратно docker-compose up -d
Готово. При этом тут в докер файле настройки и так хранятся в отдельном volume, поэтому ничего не сотрется.

Теги:
Хабы:
Закрыть

Редакторский дайджест

Присылаем лучшие статьи раз в месяц

Комментарии 143

Можно ли автоматически использовать в прокси-клиенте списки "Антизапрета"

Как показала практика, идея крайне плохая. Ибо огромное количество сервисов заблокировано для России извне.

Пока оптимальный такой выбор для РФ:

outbound

geoip:ru
geoip:private

domain:yandex.com
domain:google.com
domain:yahoo.com
domain:bing.com

domain:ru
domain:su
domain:vk.com
domain:icq.com
domain:livejournal.com

Можно использовать списки не антизапрета, а antifilter.download

Там есть список community, в котором в том числе собирают и сайты которые блокируют РФ трафик.

А как их использовать с помощью nekobox к примеру, подскажите?

Для проектов использующих формат списков *.db не подскажу. Но для XRay который использует *.dat файлы я сделал форк для себя

https://github.com/schebotar/antifilter
https://github.com/schebotar/antifilter-domain

В настройках соответственно прописывать
geosite:antifilter
geosite:antifilter-comminity
geoip:antifilter
geoip:antifilter-community

Обязательно стоит добавить domain:xn--p1ai

Это для кириллических доменов .рф. Про них все забывают, т.к. они довольно редкие, но иногда попадаются у гос. порталов. Также я для подстраховки добавил domain:by, но это уже опционально.

В дополнение:

Не знаю как в других приложениях, но в Shadowrocket на IOS происходит утечка DNS при использовании режима Config, если вручную во вкладке General не прописать нужные DNS. Если использовать режим Proxy, то утечки не происходит, даже если DNS вручную не прописаны.

но в Shadowrocket на IOS происходит утечка DNS

SagerNet об этом предупреждает в настройках, как вариант, убрать утечку можно, если далее пропускать трафик через Adguard с включённым DNS или использовать DOH в браузере.

предупреждение

Задержки 1100-1800 ms для Нидерландского сервера это норм для XTLS-Reality?

Есть способ существенно уменьшить задержки для VLESS-Reality: маскироваться под сайт, пинг до которого от VPS минимальный.

Более продвинутый способ: использовать утилиту от авторов XTLS для выбора маскировочного сайта из той же подсети: RealiTLScanner.

Раньше, по Вашему совету, 3X-UI отлично устанавливалось командами:
«git clone https://github.com/MHSanaei/3x-ui.git
cd 3x-ui
git checkout v1.4.6».

Теперь выдает это:
«Note: switching to 'v1.4.6'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.».

Что делать, куда копать?

Так раньше все то же самое было, это стандартное поведение git'а, так и должно быть.

Делать ничего не надо, все нормально, можно устанавливать дальше.

Ну и да, там в статье сказано, что при checkout стоит использовать самую свежую версию со страницы Releases - на сегодняшний день это v1.7.9, используйте ее.

Извините за нубство, но что делать дальше то после такого сообщения?

Note: switching to 'v1.4.6'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

git switch -c

Or undo this operation with:

git switch -

Turn off this advice by setting config variable advice.detachedHead to false

HEAD is now at 5487dc4 Merge pull request #434 from hamid-gh98/main
root@ubuntu:~/3x-ui#

Продолжать по инструкции из статьи, а именно, запускать docker-compose как там описано.

Это сообщение - не ошибка, просто уведомление.

И ещё раз: v1.4.6 уже не самая актуальная версия, используйте лучше последнюю со страницы Releases из гитхаба.

v1.7.9 Latest
important : after this update you need to click on "Reset to Default Configuration" and set your settings again

интересно, какие параметры слетят при этом? порт панели, адрес?

Ничего не слетает. Это сообщение относится к параметрам маршрутизации на сервере, которые очень легко возвращаются в прежнее состояние.

Поставьте

X-UI:

git clone https://github.com/alireza0/x-ui.git
cd x-ui
git checkout 1.5.5

Что касаемо настройки XTLS-Reality через панель 3X-UI, при создании подключения нужно указывать порт 443, а уже затем в правилах фаервола указывать порт сайта, под который я маскируюсь, верно?

Что вы имеете в виду под "порт сайта"? У вас прокси слушает на порту 443 (HTTPS), к сайту, под который вы маскируетесь, обращения идут тоже на 443 порт.

В правилах фаервола для разрешения входящих подключений нужно указывать тот порт, на котором у вас слушает прокси, то есть тоже 443.

Спасибо, все понял

А что насчёт port knocking?

А что насчёт него?

Им можно прикрывать сервера, уязвимые к active probing (например Softether или MS SSTP), но против сколь-более серьезных блокировок этого будет недостаточно, я о таком писал в одной из первых статей.

Как вы оцениваете вероятность, что если я запущу xtls-reality на арендованном vps, то через некоторое время через меня будут качать трафик с сайта, которым я прикрылся и мой лимит пропускной способности будет исчерпан? Например, скачивать дистрибутивы с сайта ms.

Вероятность практически нулевая.

Это кто-то должен просканировать подсеть, в которой находится ваш сервер, найти, что он отвечает с сертификатом microsoft.com, и специально начать через него зачем-то (зачем? кому это надо?) гнать трафик к сайту MS. К тому же большинство контента (особенно дистрибутивы) там лежит не непосредственно на самом домене второго уровня microsoft.com, а на всевозможных его поддоменах и технических доменах CDN.

А есть какие-то решения для arm64 серверов? Использовал форк outline vpn под arm64 но сегодня ночью видимо попал под блокировку (соединение устанавливается, но ничего не грузит)

И у XRay и у Sing-box на гитхабе есть билды под linux-arm64-v8a.

https://github.com/alireza0/x-ui завёлся через докер и смог поднять vless+reality, а 3x-ui не захотел.
Спасибо вам за ваш труд!

Сегодня в Ростове-на-Дону перестал работать shadowsocks (outline) и shadowsocks-2022. Vless на том же сервере что и ss-2022 пока работает.

На ntc.party уже предположили, что блокируют все неопознанные протоколы.

Да, ночью outline отвалился, думал может блокируют больше порты, пробовал перейти на 443 и 80 - не помогло.

Поднял vless + reality на том же сервере - всё заработало.

Vless + Reality
Vless + Reality

Streisand отлично завёлся на Mac с M1 и даже удалось Rules настроить, интерфейс правда немного подтапливал при настройке, но всё в итоге получилось. Выдаёт скорость и стабильность работы лучше чем HiddifyNext.

Вау, вот это скорость.

Сделать настройки Routing в конфиге, и в зависимости от ID пользователя

Подскажите, как бы выглядел конфиг, в случае:

3 подключения к серверу, у всех "серые" внешние ip. На 1-ом есть RDP:3389, на 2-ом HTTP:81 и SSH:22, на 3-м ничего, обычный клиент. 3-ему надо подключаться к сервисам 1-ом и 2-ом.

А если добавить 4-ого, за которым есть сеть, скажем, 10.10.10.0/24, есть ли возможность подключаться к хостам в сети за 4-ым клиентом?

Возможно через tun2socks..?

Да, я понимаю, что всё это не задачи proxy и тут, наверно, логичнее в cloak и WG сверху, но не хочется этого оверхэда.

Спасибо за ваш труд)

3-ему надо подключаться к сервисам 1-ом и 2-ом.

А если добавить 4-ого, за которым есть сеть, скажем, 10.10.10.0/24, есть ли возможность подключаться к хостам в сети за 4-ым клиентом?

И то и то возможно, если настроить reverse proxy в XRay, но там специальным образом настраивать надо сразу и на сервере и на клиентах, и без бутылки просто так не разобраться. Статья на очереди :)

Спасибо за статью!

Однако я здесь ожидал увидеть объяснения терминов "на пальцах"© для тупых, в том числе:

  1. Описания терминов X-UI, 3X-UI, XRay, V2Ray, VLESS, VMESS, XTLS, Reality, XTLS-Reality, sing-box, seed-box. Что из них дашборд, что из них протокол, что из них ядро, и что такое в данном контексте "ядро"? Не ядро ОС же? Как они сочетаются, какая у них иерархия? Единственное, что из этого зоопарка знаю - то, что 3X-UI и X-UI - дашборды. Конкретно X-UI уже три месяца пользуемся благодаря вашим инструкциям и в ус не дуем;

  2. Чем так серьёзно, простыми словами, отличаются протоколы ShadowSocks от ShadowSocks-2022? Будет ли версия 2023?

  3. Непонятны аббревиатуры XTLS, Reality и почему они иногда работают вместе?

Вдохновившись весенними статьями автора, в начале лета я на VPS скачал с Гитхаба Xray-1.8.1 (позднее пробовал и 1.8.4). Кинул его в /opt/xray, не стал заворачивать в Docker.

config.json
{
  "log": {
    "loglevel": "info"
  },
  "routing": {
    "rules": [],
    "domainStrategy": "AsIs"
  },
  "inbounds": [
    {
      "port": 443,
      "protocol": "vless",
      "tag": "vless_tls",
      "settings": {
        "clients": [
          {
            "id": "<CENSORED>",
            "email": "<CENSORED>",
            "flow": "xtls-rprx-vision"
          }
        ],
        "decryption": "none"
      },
      "streamSettings": {
        "network": "tcp",
        "security": "reality",
        "realitySettings": {
            "show": false,
            "dest": "<DOMAIN>:443",
            "xver": 0,
            "serverNames": [
                "<DOMAIN>"
            ],
            "privateKey": "<CENSORED>",
            "minClientVer": "",
            "maxClientVer": "",
            "maxTimeDiff": 0,
            "shortIds": [
                "<CENSORED>"
            ]
        }
      },
      "sniffing": {
        "enabled": true,
        "destOverride": [
          "http",
          "tls"
        ]
      }
    }
  ],
  "outbounds": [
    {
      "protocol": "freedom",
      "tag": "direct"
    },
    {
      "protocol": "blackhole",
      "tag": "block"
    }
  ]
}

xray.service
[Unit]
Description=Xray Service
Documentation=https://github.com/xtls
After=network.target nss-lookup.target

[Service]
User=nobody
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE
AmbientCapabilities=CAP_NET_ADMIN CAP_NET_BIND_SERVICE
NoNewPrivileges=true
ExecStart=/opt/xray/xray run -config /opt/xray/config.json
Restart=on-failure
RestartPreventExitStatus=23
LimitNPROC=10000
LimitNOFILE=1000000

[Install]
WantedBy=multi-user.target

В качестве клиентов использовались nekoray-linux (AUR-версия) и v2rayNG-1.8.5.

Через непродолжительное время после запуска сервиса началась повышенная (чуть ли не на всю ширину канала) сетевая активность между моим 443-м портом и всякими иранскими IP. Выключаю - трафик иссякает. Запускаю - вновь оживает.

Естественно, я нигде не публиковал никакие доступы. На VPS до того уже более года крутились WG и ShadowSocks-rust, никаких инцидентов не было замечено.

Тут очень интересно будет узнать, в какой AS находился сервер, под какой именно домен маскировались с reality, шла ли куда-то "активность" во направлении дальше (нет смысла делать запросы в один конец раз у нас прокси, да?), а самое главное - что было видно в логах процесса в момент подобной активности.

Потому что все это звучит очень странно, на грани фантастики. Как я уже писал, мы ради интереса мониторили трафик Wireshark'ом, и ничего подозрительного не обнаружили вообще, плюс у одного товарища на нескольких подобным образом настроенных серверов стоит Munin и мониторит в том числе и трафик на иетерфейсах - там никакой аномальной активности. Исходники Xray и Nekobox тоже просматривали (не аудит, да, но специально искали места, где могли делаться какие-либо левые запросы наружу) - там тоже все чисто. Если кто-то найдет и докажет что-то подобное в сорсах - я тому лично пару сотен долларов отправлю криптой в вознаграждение :)

И более того, о подобном никто кроме вас ни слова не упоминали на гитхабе, публичных форумах, и т.д., то есть подобное "происходит" только у вас. Логично предположить, что это или просто какой-то DDoS, когда сканеры наткнулись на ваш сервер, нашли там ответ с интересным им SNI и погнали, либо на вашем IP за год до этого крутился другой сервер с чем-то интересным, либо что-то ещё подобное.

AS41436, маскировка под www.kamatera.com. Графики входящего и исходящего траффика в панели управления хостинга были симметричными. Логи процесса, к сожалению, не сохранились.

До запуска Xray на 443-м порту продолжительное время и без нареканий работал MTPROTO прокси mtg. Для всех сервисов использовались уникальные сгенерированные пароли.

Сам понимаю, что история очень мутная вышла.

А есть ли версия X-UI, которую можно завести под Ubuntu 14.04? Я понимаю, что дистр старый, но на VPS особо не пообновляешься.

Когда внутри докера, то по идее без разницы, в чем оно крутится, главное чтобы сам докер завелся.

Но 14.04 - оно уже давно EoL, даже обновления безопасности не получает, использовать такое - это как сидеть на бочке с порохом. Лучше уж обновиться (в случае с VPS нередко это будет "заказать новый VPS со свежей системой, перенести сервисы туда, грохнуть старый VPS).

Спасибо за очередной монументальный материал! Снимаю шляпу, очень полезная вещь

Здравствуйте! Зарегистрировался только чтобы выразить огромную благодарность за ваши материалы. Даже я, человек, который гораздо более далек от темы сетей, чем средний айтишник, смог поставить себе работающий XTLS-Reality.

Я предполагаю, что в скором времени в связи с законом по удалению материалов по обходу блокировок из нашего православного рунета, эти статьи (я надеюсь этого не случится) будут удаляться с Хабра, так что можно ли будет читать Вас где-нибудь еще, например в Телеграм канале?

"Можно, ага. Качаете geoip.db и geosite.db вот отсюда: https://github.com/L11R/antizapret-sing-box-geo
И подсовываете их в ваш клиент. После этого настраиваете маршрутизацию как обычно, например, в качестве дефолтного маршрута выбираете bypass (direct), а через прокси пускаете IP-адреса по тегу geoip:antizapret и домены по тегуgeosites:antizapret

Также есть очень интересные списки на https://github.com/v2fly/domain-list-community"

Можете, пожалуйста, объяснить, как это заставить работать с Shadowrocket?

А вы не сталкивались с тем, что при использовании Vless + Reality могут переодически рваться ssh сессии? Из-за чего это может быть?

У меня Билайн. Нахожусь в Ставрополье. Ни один протокол из x-ui не работает. Что с маскировкой, что без нее. Также не работает WireGuard. Некоторые серверы не доступны для http протокола. Похоже, действительно, блочат все, что не определяется и не попало в белый список.

На хабр вы как-то попали - значит HTTPS не блочат, а значит и VLESS должен работать.

Не хватает подробностей, какие именно протоколы пробовали, на VPS какого хостера и с какими настройками - в XRay (и, соответственно, X-UI) можно настроить около десятка комбинаций, поэтому "ни один протокол не работает" звучит как-то слишком. Да и в целом, вы вообще первый (не только на Хабре), кто сообщил о том, что перестало работать вообще все, так что конкретно в этом случае я бы скорее искал проблему где-то ещё, а не в блокировках РКН.

VLESS. 443 порт, reality, uTLS, остальное по-дефолту. Что еще нужно включить, настроить?

Тогда интересно посмотреть, что видно в логах клиента и сервера в момент попыток подключения. Плюс попробовать использовать другой домен для маскировки.

Кстати, в чатике Amnezia VPN написали интересное

Господа! Новости из будущего, пока не проснулись.

Со стороны теле2 и некоторых местных проводных провайдеров наблюдается блокировка ip, где раньше были классические ВПН (опенВПН, вг). Блочится именно ip.

На мегафоне, мтс, билайне всё пока работает в штатном режиме. Проблема наблюдается на двух серверах инферно, которые были засвечены на классических протоколах. Vless на незасвеченных работает нормально..

Если это действительно так, то это многое объясняет

Дополню комментарий в чатике. Регион - Восточная Сибирь. Блокировка наблюдалась со стороны ТЕЛЕ2, Ростелекома, пары местных провайдеров проводных. Помимо OpenVPN и WG также под бан попали сервера, где был установлен Outline. Все сервера были переведены на VLESS ранее, но с этих провайдеров не достучаться. На серверах из той же подсети, где сразу ставился VLESS - на всей провайдерах полёт отличный.

Похоже на локальные эксперименты. Ну и повод сразу использовать VLESS..

Приветствую, к сожалению как новый пользователь сайта не могу писать в нужной теме, мог бы кто-нибудь подсказать как сбросить настройки в панели x-ui? Поменял порт в настройках после установки и теперь по указанному порту не могу к ней подключиться. Upd переставил все заново и все отлично завелось, единственное что с виндой и андроидом работает, а на айфоне v2box отключает соединения как только переходишь в браузер или другое приложение, это какой-то баг самого приложения?

В консоли вводите x-ui. Дальше все поймёте.

а на айфоне v2box отключает соединения как только переходишь в браузер или другое приложение, это какой-то баг самого приложения

Да, баг конкретно v2box - у меня, когда тестировал, оно тоже регулярно вылетало (судя по всему, из-за нехватки памяти).

Нехватки оперативной памяти или постоянной? На имеющемся айфоне постоянная память забита до упора. И хотел бы поинтересоваться что можно сделать для безопасности впс кроме смены стандартного порта ссш и установки ограничения на количество попыток ввода пароля, нет ли необходимости что-то с самой вебмордой делать?

Оперативной памяти.

Попробуйте Streisand, люди пишут, что работает очень неплохо.

С вебмордой - прикрутить TLS (хотя бы самоподписанный), а по-хорошему вообще не светить наружу, добавить на сетевой интерфейм на сервере виртуальный фейковый IP, заставить морду слушать на нем, и заходить на нее через прокси-клиент. Но там рисково, в случае неправильной настройки есть риск остаться без морды :)

А может кто подсказать, в некобокс для винды предусмотрен вообще автозапуск подключения при старте и киллсвитч? Не смог найти в настройках. И странный момент, при включенных режиман тюн и прокси, но не включенном соединении к впс, браузер и дискорд конекта не имеют, при это прога для удаленного рабочего стола parsec спокойно подключилась к компу, это получается прога где-то что-то не прикрывает что доступ все таки есть?

при это прога для удаленного рабочего стола parsec спокойно подключилась к компу, это получается прога где-то что-то не прикрывает что доступ все таки есть?

Прога может тупо игнорить настройки системного прокси, и при этом пытаться лезть в интернет перебирая интерфейсы, если через интерфейс с дефолтным маршрутом вылезти в интернет не получилось.

Объясните пожалуйста как сделать SSL на 3x-ui 🙏🏼

В настройках панели вставьте ссылки на файлы сертификата и ключа, там же есть эти поля.

Пользуюсь прокси, и некоторые сервисы/приложения каким-то образом определяют, что я сижу через прокси, как они это делают?

Для меня стало большим откровением, что современные браузеры при использовании любых прокси или VPN сливают ваш IP адрес через WebRTC!

Только Tor Browser и Brave (после активации соответствующей опции) блокируют слив адреса либо приходится использовать плагин Ublock Origin (который, к счастью, работает в Kiwi Browser на Android) с магической командой блокировки *##+js(nowebrtc).

IP не сливается через WebRTC при использовании режима TUN (проверял на Nekobox+Win10). Но если не активировать TUN и использовать стандартный режим "системного прокси" - то да, приходится затыкать его плагинами браузера.

https://habr.com/ru/articles/731608/ можете ответить по этой статье, просто аккаунт новый не могу там написать комментарий. Я настроил XRay с XTLS-Reality по инструкции, но возник вопрос почему некоторые сайты видят моё настоящие местоположение? Например google упорно видит меня в России и некоторые другие сайты. Это так и должно быть или я что настроил не правильно? Мне кажется когда речь идет о полной маскировке такого быть не должно.

Потому что они определяют вас не только по GeoIP вашего сервера. Во-первых, и сам GeoIP может быть неправильный - сервер где-нибудь в Амстердаме, а IP-адрес в некоторых базах до сих пор числится как российский (особенно если зостер российский).

Во-вторых, для Гугла, например, более приоритетными являются данные с геолокации устройств (особенно Android), вплоть до того, что если вы (или кто-то ещё из пользователей вашего прокси) выходил через него и засвечивал геолокацию в РФ, то со временем он может начать считать этот адрес российским, не взирая на GeoIP.

В-третьих, см. вопрос про IPv6 в статье. Если у вас провайдер его поддерживает (или, например, активен Teredo в системе), а в клиенте он не включен, то трафик до доступных по IPv6 сервисов (написано того же Гугла) может идти напрямую вместо прокси.

Здравствуйте. Подскажите, хочу в x-ray использовать свой собственный dns резолвер. На vps с Ubuntu установлен x-ray сервер (reality), так же на нем же имеется установленный unbound и настроены параметры кэширования dns запросов. Unbound настроен в качестве системного резолвера (127.0.0.1 в /etc/resolv.conf), разрешены запросы с локалхоста и частной сети 10.0.0.0/8, порт 53 открыт для частной подсети 10.0.0.0/8. Так вот, задача - заставить x-ray использовать именно мой системный dns резолвер и полностью закрыть вопрос с утечкой dns. Это возможно?

Если найдете решение - напишите ответом на коммент сюда же, плиз. Я так и не смог на серверной стороне это реализовать. Как костыль использую настройку dns в приложении-клиенте на телефоне.

Для серверной части как раз-таки все понятно.

Добавляем в конфиг:

"dns": {
     "servers": [
         "172.0.0.1" //в моем случае
     ],
     "queryStrategy": "UseIP",
     "disableCache": true,
     "disableFallback": true,
     "disableFallbackIfMatch": true,
     "tag": "dns_inbound"
 },

Но вот для клиента на ios с использованием правил маршрутизации не могу сделать (Shadowrocket, foXray, Streisand) - получается там 127.0.0.1 - это системный днс клиента.

Есть мысль, сделать костыль - отдельный прокси для днс запросов (дополнительный inbound, outbound и routing для проксирования днс запросов на свой сервер). Но уверен, должен быть более простой вариант

На ios в настройках ShadowRocket в разделе Config строчка General - там есть настройки днс - я туда просто вбил DoH-ссылку. На dnsleaks утечек нет при такой настройке.

Дело в том, что у меня не DoH. Как ниже написал ТС, при режиме Прокси - все днс запросы по умолчанию идут через системный днс моего впс. Но, естественно, мне нужен tun режим с моими правилами роутинга.

В случае использования proxy-режима этот DNS будет использован из коробки, ничего делать не надо.

В случае использования TUN-режима (как обычно на мобильных клиентах), можно сделать в inbounds

{
      "protocol": "dns",
      "tag": "dns"
},

а в routes

"routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "port": 53,
        "outboundTag": "dns"
      },

Тогда все запросы на 53 порт будут перехватываться и отправляться на встроенный DNS.

Спасибо, попробую!

Но не понятно, что тогда в настройках днс клиента указывать? В том же Straisand или Shadowrocket необходимо dns вписать в настройках

В настройках DNS клиента указывать все что угодно - прокси любые запросы на 53 порт будет перехватывать и отправлять на встроенный сервер.

Точно верхний блок в inbounds?

В x-ui такой конфиг выдает ошибку:

Failed to start: main: failed to load config files: [bin/config.json] > infra/conf: failed to load inbound detour config. > infra/conf: unknown config id: dns

{
  "api": {
    "services": [
      "HandlerService",
      "LoggerService",
      "StatsService"
    ],
    "tag": "api"
  },
  "dns": null,
  "fakeDns": null,
  "inbounds": [
    {
      "listen": null,
      "port": 0,
      "protocol": "dns",
      "settings": null,
      "sniffing": null,
      "streamSettings": null,
      "tag": "dns"
    },
    {
      "listen": "127.0.0.1",
      "port": 55555,
      "protocol": "dokodemo-door",
      "settings": {
        "address": "127.0.0.1"
      },
      "sniffing": null,
      "streamSettings": null,
      "tag": "api"
    },
    {
      "listen": null,
      "port": 8443,
      "protocol": "vless",
      "settings": {
        "clients": [
          {
            "email": "111",
            "flow": "xtls-rprx-vision",
            "id": "11111111"
          },
          {
            "email": "222",
            "flow": "xtls-rprx-vision",
            "id": "22222222"
          },
          {
            "email": "333",
            "flow": "xtls-rprx-vision",
            "id": "33333333"
          }
        ],
        "decryption": "none",
        "fallbacks": []
      },
      "sniffing": {
        "destOverride": [
          "http",
          "tls",
          "quic",
          "fakedns"
        ],
        "enabled": true
      },
      "streamSettings": {
        "network": "tcp",
        "realitySettings": {
          "dest": "www.microsoft.com:443",
          "maxClient": "",
          "maxTimediff": 0,
          "minClient": "",
          "privateKey": "00000000",
          "serverNames": [
            "microsoft.com",
            "www.microsoft.com"
          ],
          "settings": {
            "fingerprint": "firefox",
            "publicKey": "00000000",
            "serverName": "",
            "spiderX": "/"
          },
          "shortIds": [
            "xxx",
            "yyy",
            "zzz"
          ],
          "show": false,
          "xver": 0
        },
        "security": "reality",
        "tcpSettings": {
          "acceptProxyProtocol": false,
          "header": {
            "type": "none"
          }
        }
      },
      "tag": "inbound-8443"
    }
  ],
  "log": {
    "loglevel": "warning"
  },
  "outbounds": [
    {
      "protocol": "freedom",
      "settings": {}
    },
    {
      "protocol": "blackhole",
      "settings": {},
      "tag": "blocked"
    }
  ],
  "policy": {
    "levels": {
      "0": {
        "statsUserDownlink": true,
        "statsUserUplink": true
      }
    },
    "system": {
      "statsInboundDownlink": true,
      "statsInboundUplink": true
    }
  },
  "reverse": null,
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "inboundTag": [
          "api"
        ],
        "outboundTag": "api",
        "type": "field"
      },
      {
        "outboundTag": "dns",
        "port": 53,
        "type": "field"
      }
    ]
  },
  "stats": {},
  "transport": null
}

Да, верхний блок в outbounds конечно же, опечатался.

Конфиг работает.

Но клиенты с ios все равно не проходят тест на утечку ip. Shadowsocks, foXray и Streisand - везде одинаково. В настройках этих приложений указывал дес сервер 127.0.0.1 и 8.8.8.8 - без разницы.

Подсказали конфиг на гите:

{
  "dns": {
    "servers": [
      {
        "address": "127.0.0.1",
        "port": 53
      }
    ]
  },
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "inboundTag": ["dns-in"],
        "outboundTag": "dns-out"
      },
      // your other rules here
    ]
  },
  "inbounds": [
    {
      "port": 53,
      "tag": "dns-in",
      "protocol": "dokodemo-door",
      "settings": {
        "address": "127.0.0.1",
        "port": 53,
        "network": "tcp,udp"
      }
    },
    // your other inbounds here
  ],
  "outbounds": [
    {
      "tag": "dns-out",
      "protocol": "dns",
      "settings": {
        "network": "tcp,udp",
        "address": "127.0.0.1",
        "port": 53
      }
    },
    // your other outbounds here
  ]
}

Я по этому образцу откорректировал свой конфиг (x-ui от alireza0). При такой настройке x-ray запускается, но клиенты без интернета:

{
  "api": {
    "services": [
      "HandlerService",
      "LoggerService",
      "StatsService"
    ],
    "tag": "api"
  },
  "dns": {
    "servers": [
      {
        "address": "127.0.0.1",
        "port": 53
      }
    ]
  },
  "fakeDns": null,
  "inbounds": [
    {
      "listen": null,
      "port": 53,
      "protocol": "dokodemo-door",
      "settings": {
        "address": "127.0.0.1",
        "network": "tcp,udp",
        "port": 53
      },
      "sniffing": null,
      "streamSettings": null,
      "tag": "dns-in"
    },
    {
      "listen": "127.0.0.1",
      "port": 62789,
      "protocol": "dokodemo-door",
      "settings": {
        "address": "127.0.0.1"
      },
      "sniffing": null,
      "streamSettings": null,
      "tag": "api"
    },
    {
      "listen": null,
      "port": 443,
      "protocol": "vless",
      "settings": {
        "clients": [
          {
            "email": "111",
            "flow": "xtls-rprx-vision",
            "id": "111"
          },
          {
            "email": "222",
            "flow": "xtls-rprx-vision",
            "id": "222"
          },
          {
            "email": "333",
            "flow": "xtls-rprx-vision",
            "id": "333"
          },
          {
            "email": "444",
            "flow": "xtls-rprx-vision",
            "id": "444"
          }
        ],
        "decryption": "none",
        "fallbacks": []
      },
      "sniffing": {
        "destOverride": [
          "http",
          "tls",
          "quic",
          "fakedns"
        ],
        "enabled": true
      },
      "streamSettings": {
        "network": "tcp",
        "realitySettings": {
          "dest": "www.microsoft.com:443",
          "maxClient": "",
          "maxTimediff": 0,
          "minClient": "",
          "privateKey": "000",
          "serverNames": [
            "microsoft.com",
            "www.microsoft.com"
          ],
          "settings": {
            "fingerprint": "firefox",
            "publicKey": "000",
            "serverName": "",
            "spiderX": "/"
          },
          "shortIds": [
            "111",
            "222",
            "333",
            "444"
          ],
          "show": false,
          "xver": 0
        },
        "security": "reality",
        "tcpSettings": {
          "acceptProxyProtocol": false,
          "header": {
            "type": "none"
          }
        }
      },
      "tag": "inbound-443"
    }
  ],
  "log": {
    "loglevel": "warning"
  },
  "outbounds": [
    {
      "protocol": "dns",
      "settings": {
        "address": "127.0.0.1",
        "network": "tcp,udp",
        "port": 53
      },
      "tag": "dns-out"
    },
    {
      "protocol": "freedom",
      "settings": {
        "domainStrategy": "AsIs"
      }
    },
    {
      "protocol": "blackhole",
      "settings": {},
      "tag": "blocked"
    }
  ],
  "policy": {
    "levels": {
      "0": {
        "statsUserDownlink": true,
        "statsUserUplink": true
      }
    },
    "system": {
      "statsInboundDownlink": true,
      "statsInboundUplink": true
    }
  },
  "reverse": null,
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "inboundTag": [
          "dns-in"
        ],
        "outboundTag": "dns-out",
        "type": "field"
      },
      {
        "inboundTag": [
          "api"
        ],
        "outboundTag": "api",
        "type": "field"
      }
    ]
  },
  "stats": {},
  "transport": null
}

Может еще какие-то особенности для клиента есть?

Помогите подружить AdGuard Home и 3x-ui (или x-ui), которые установлены на одном сервере и оба хотят использовать 443 порт?

Чуть подробнее:
1. получаю сертификаты letsencrypt
2. ставлю AgH через snap, настраиваю вебморду на субдомене, указываю сертификаты, указываю порт 443 (ниже объясню почему только его)
3. ставлю 3x-ui скриптом с гитхаба, настраиваю его через вебморду на основном домене, (так же указываю сертификаты ssl в панели) как указанно в соседней статье тоже с портом 443 (речь про unbound, не панель), с активированным переключателем Reality, flow - xtls-rprx-vision/

В такой конфигурации оба приложения слушают 443 порт, но работает только AgH. Если перекинуть AgH через его вебморду на другой порт, например 442, то начинает работать 3x-ui, но при этом у AgH остается рабочей только вебморда на 442, сам днс не работает - при добавлении ссылки на DoH в клиенте AdGuard на ios с портом 442 (как и с любым другим, в общем-то) перестают открываться k.st сайты, и вебморда не видит никаких обращений к ней в разделе журнала.

Получается нужно как-то на 443 порту подружить и AgH и 3x-ui потому как первый вообще не работает через порты отличные от 443, а второму нужен этот же порт для маскировки под другой сайт.

Я понимаю, что оба сервиса не могут дружить на одном и том же порту без сторонней помощи от например nginx, но как его настроить я не знаю)) помогите пожалуйста подробной инструкцией?

Можно легко подружить x-ray и другие сервисы, работающие на 443 порту с помощью nginx и его модуля ssl_preread (по sni)

Так у меня на одном впс работает много всего на 443 порту.

https://nginx.org/ru/docs/stream/ngx_stream_ssl_preread_module.html

Я знаю, что это возможно) суть в том, что я не знаю как именно это делается) мне бы инструкцию)

stream {
  map $ssl_preread_server_name $name {
    xraydomain.tld xray;
    www.xraydomain.tld xray;
    domain1.tld domain1;
    www.domain1.tld domain1;
    domain2.tld domain2;
    www.domain2.tld domain2;
  }
  upstream xray {
    server 127.0.0.1:1021;
  }
  upstream domain1 {
    server 127.0.0.1:1022;
  }
  upstream domain2 {
    server 127.0.0.1:1023;
  }
  server {
    listen 443 reuseport;
   # listen [::]:443 reuseport;
    proxy_pass  $name;
    ssl_preread on;
  }
}

Ну по примеру такого конфига сделайте

о, а вот тут уже прям большое спасибо!
уточняющий вопрос - я правильно понимаю, что при таком конфиге физически на 443 порту сидит только nginx, а далее он уже перенаправляет на 1021, 1022, 1023 (как в примере)?

Да. Порты 1021, 1022 и т.д. меняйте на удобные вам. И не забудьте в конфигах этих сайтов/сервисов такие же порты выставить

Ну и в конфиге самого xray тоже порт сменить не забудьте

Так ведь в Reality весь смысл в том, чтобы он на 443 порту был и маскировался под другой сайт тоже на 443? Он вроде даже вообще не заводится если при создании inbound в панели указать не 443 порт.

Для внешнего наблюдателя это будет выглядит как сервер на 443 порту, он ничего не будет знать про 1021, 1022 и другие.

Одно НО - такая схема ок, если вы используете чистый VLESS (без Reality) или используете Reality, но прикрываясь своим же доменом (так называемая схема steal from yourself). Прикрываться же чужим популярным доменом в этом случае затея сомнительная - SNI передается в открытом виде, то есть факт наличия SNI-прокси на сервере виден невооружённым глазом. На настоящем сервере (под который вы маскируетесь) SNI-прокси с таким дополнительным доменом нет, а у вас есть, и это уже очень подозрительно.

О, кстати отличная идея. На этом же впс у сеня есть свои сервисы/сайты за веб сервером. Главные условия tls 1.3 и h2 - не проблема. И тогда на свой же домен на этом впс можно ссылаться в Reality - так еще и задержка будет минимальная!)

Простите, но у меня в голове случилась рекурсия от отсутствия опыта). Получается в конфиге nginx один и тот же домен будет упоминаться дважды? как-то так:

map $ssl_preread_server_name $sni_name {
mydomain.com reality; #сайт под который маскируемся
mydomain.com site1; #свой же сайт
aaa.mydomain.com site2; #субдомен своего сайта
default reality;
}

Что-то тут не то.
Или так и должно быть?

map $ssl_preread_server_name $sni_name {
www.microsoft.com reality; #сайт под который маскируемся
mydomain.com site1; #свой же сайт
sub.mydomain.com site2; #субдомен своего сайта
default reality;
}
upstream reality {
server 127.0.0.1:8443;
}
upstream site1 {
server 127.0.0.1:8444;
}
upstream site2 {
server 127.0.0.1:8445;
}
server {
listen 443 reuseport;
proxy_pass $sni_name;
ssl_preread on;
}

Вот более наглядно. Здесь меняете mydomain.com и sub.mydomain.com на свои значения. www.microsoft.com - адрес для xray reality, его можете оставить (но тогда и в самом x-ray такой же должен быть). Все порты, кроме 443 меняйте на свое усмотрение

На 1 коммент выше MiraclePtr пишет:

если вы ... используете Reality, но прикрываясь своим же доменом (так называемая схема steal from yourself). Прикрываться же чужим популярным доменом в этом случае затея сомнительная

Далее вы же ему отвечаете:

О, кстати отличная идея. На этом же впс у сеня есть свои сервисы/сайты ... И тогда на свой же домен на этом впс можно ссылаться в Reality

...И в коде пишете в примере microsoft.com. Вот в этом месте у меня голова ломается) Как я понимаю, вместо microsoft.com надо вписать все же свой сайт. Но тогда получается, что он будет прописан дважды:

  1. как сайт, за которым прячемся,

  2. как реальный свой сайт.

Вот я и спрашиваю - так и должно быть, что он (свой домен) будет дважды прописан, или это ошибка, и прописывать надо как-то иначе?

А, вот вы о чем)

Я пока не проверял этот вариант. Так, идея просто, надо думать

схема steal from yourself

Подскажете все же как это прописать в nginx?

Почти точно так же, как и для обычного сайта с TLS-сертификатами.

Например, XRay слушает на 443 порту с Reality, в качестве "dest" у него указан "127.0.0.1:8443". Nginx со своим сайтом с настроенным TLS слушает на 127.0.0.1 и порту 8443.

Спасибо за наводку. Нашел еще очень полезный пример конфигов xray и nginx для разруливания по SNI:

https://github.com/chika0801/Xray-examples/tree/main/VLESS-XTLS-uTLS-REALITY/nginx_sni_shunting

В итоге настроил маскировку в reality под собственный сайт на одном сервере с xray. Разницы в скорости серфинга или уменьшение задержки не заметил (по сравнению с microsoft.com в качестве dest)

Подскажите, как можно измерить latency моего подключения xray для сравнения вариантов?

Почему-то перестал работать протокол ss из этого гайда (таймаут), хотя никаких настроек не менял, vless на том же сервере продолжает работать.

Это с моей стороны проблему нужно искать или где-то еще?

У вас на это сервере случайно до vless и ss никаких популярных VPN-серверов не стояло?

В период недавнего обострения было замечено, что РКН во-первых банил все неопознанные протоколы (к которым относится в том числе и ss), а во-вторых, банил IP-адреса, к которым за какое-то время до этого подключались по общеизвестным VPN-протоколам.

Других объяснений нет.

Настройка маршрутизации и клиентов. Как настроить, чтобы на российские сервера и сайты доступ шел напрямую, без прокси? для Shadowrocket на iOS. Если нужен еще GeoIP, то идем на MaxMind Geolite2 и регистрируемся там

Не осилил их регистрацию. Я нахожусь на шаге где хз как получить geoip в shadowrocket)

Общался с их саппортом — они не предоставляют услуги РФ пользователям. Все РФ айпишники заблочены + Все списки айпи по хостам, проксям и ВПН они тоже блочат.

ЗЫ Во, комментировать теперь могу :)

На данный момент на MaxMind Geolite2 невозможно зарегистрироваться с российских ip. Даже через прокси или впн. За меня регался знакомый из сша, вводил мои данные, мою почту. В итоге мне на почту пришло письмо с подтверждением регистрации

ага, справился тем же методом) Ты американец, а я чех :)

Можно тупой вопрос? ) пользуюсь foxray на ios и бывает так что приложение просто дропает соединение, вырубается, при заходе на некоторые сайты в com формате.Управление памятью в приложении включал/выключал, один фиг, проблема остается.Кто то сталкивался? Решили ли как то проблему?

Такая же ерунда часто бывает. Запускаю подключение, перехожу по порядку на 3 разные сайта dns leak test - на последнем 100% уже сброшено подключение. Перешел на shadowrocket и straisend

как можно shadowrocket сейчас приобрести ? с мобильных операторов работает, если да с каких?

В appstore приобретал. Через мтс.

Поставьте streisand - очень неплохой клиент! И бесплатный.

Поставил себе и друзьям Straisend, работает как часы.

Очень благодарен. Бросил настройки для ру в котоящик и адреса разные показывает для ру и неру (только, зараза, один сайт находит адрес в российском городе у границы, другой нормально показывает город забугровые, то тоже соседняя страна; наверное, стоит уехать подальше, с сашу что ли). Только вот не понятно, что делать с торрент клиентом, ошибками сыплет в логах работы котоящика - возможно как-то торрент убрать из тоннеля? Ведь для торрент-трафика не нужен прокся, да и сервер не рад с его лимитом по трафику.

Не работает полноценно в некоящике - страницы не грузит, только после перезагрузки соединения. Увы, но универсальности и легкости не получилось как и всегда.

только, зараза, один сайт находит адрес в российском городе у границы, другой нормально показывает город забугровые, то тоже соседняя страна

а правила только для домена стоят, или для GeoIP тоже?

если сайты показывают один и тот же IP, но разное местоположение, то вполне возможно что хостер блок адресов приобрел недавно и просто GeoIP базы не везде еще обновились.

Только вот не понятно, что делать с торрент клиентом, ошибками сыплет в логах работы котоящика - возможно как-то торрент убрать из тоннеля?

Sing-box не умеет детектировать торрент-протокол. XRay заявляет что умеет (можно некобокс переключить в некорей), но как оно работает на практике не проверял.

Если не использовать TUN-режим, а работать через прокси, то в принципе все просто - системный прокси не ставим, в браузере прописываем ручками (есть куча расширений для переключения прокси к браузере), в итоге браузер бегает через проксю, а все остальные напрямую

Получается некобокс и не нужен тогда, а просто параметры прокси прописывать в браузерах? Там и конкретные домены можно указывать? А то рф сайты заблокировали иностранные запросы (госсайты часто), а иностранные ру заблокировали. Как будто на острове сидишь.

Некобокс все равно пригодится для удобного конфигурирования и запуска прокси. Опять же, настройки роутинга в нем можно указать, чтобы на российские сайты запросы шли напрямую, а на иностранные через проксю. То, что я предлагаю - Nekobox из настроек генерирует конфиг и запускает прокси сервер, но не прописывает его в системные настройки. Вы прописываете его вручную (или включаете расширением браузера) только в тех приложениях, где вам надо.


Хотя, можно и без него, используя только консольный sing-box. Но тогда придется конфиг полностью писать вручную :)

Прошу прощения, но я в этом не понимаю. Я прописал в поле geoip:, вбил конфиг в json. Но сеть отрубается и работает только после обновления подключения некобокс и в логах он постоянно пишет, что соединение оборвано и флеймит ошибками с адресами как-будто лимит соединений на порт превышен (забыл уже, удалил конфиг). Так как есть торрент, то всё-таки это не решение для авто-прокси, но я теперь не знаю, что вбивать в настройки расширения в браузере. На сервере крутится марзбан с пользователями. Я попробовал вбить созданное в марзбан имя и пароль от шадоусокс, но не работает (он же как-то по сгенерированным ключам работает что ли, ведь остальные протоколы не имеют пароля, а только строку с ай-ди). Там же есть: Vmess, Vless, Trojan, Shadowsocks. Порт 1080, 8080... Наверное, нельзя подружить плагин и марзбан, там протоколы разные и данные?

  1. Запускаете в Nekobox подключение к вашему серверу как обычно (правой кнопкой мыши и Start)

  2. Галочку TUN-mode и System proxy не ставите.

  3. Nekobox внизу окна посередине пишет адрес (127.0.0.1) и порт локального прокси (например, 2080).

  4. В плагине браузера вбиваете этот адрес и порт, если требует тип прокси - то SOCKS5 или HTTP.

nekobox_core grpc server listening at 127.0.0.1: ... Это? Не работает плагин. А логин и пароль не нужны? Только http, сокс4-5 не поддерживает браузер, пишет плагин SwitchyOmega.

А всё, заработало. Не тот порт указал. Получается, что теперь торрент идёт через неко, но тот его пускает напрямую без прокси? Чтобы пускать программы другие через прокси, то надо тюн включать?

Получается, что теперь торрент идёт через неко, но тот его пускает напрямую без прокси? Чтобы пускать программы другие через прокси, то надо тюн включать?

эм, нет. если вы не ставите в Nekobox ни одну из галочек сверху (TUN/прокси), то через него идет только трафик тех приложений, в которых вы явно прописали его локальный адрес и порт.
то есть из браузера (где у вас расширение-свитчер) - идет, а из торрента не идет, торрент-клиент сразу подключается напрямую безо всяких прокси.

Если нужно завернуть трафик вообще всех без исключения приложений на прокси-сервер - то да, включайте TUN

Да, точно, я же об этом и подумал, но потом, что неко сидит на своём порте. Спасибо большое. Очень благодарю за рекомендации.

А на уровне приложений нельзя в неко прописать конкретные приложения для проксирования их трафика? Есть всякие игровые магазины, еще браузеры (тут прям можно в настройках прокси в браузере указать порт с неко?), клиенты игр...

Спасибо! Спасибо! Спасибо! (-:

А на уровне приложений нельзя в неко прописать конкретные приложения для проксирования их трафика?

Не, такой фичи к сожалению нет.

А на уровне приложений нельзя в неко прописать конкретные приложения для проксирования их трафика?

Кстати, я был неправ. Кажется, можно. Судя по документации Sing-box такое умеет, и в Nekobox свежем есть такая опция в окошке настроек Tun Settings, называется Bypass Process Name. Ну и работать, судя по всему, будет только для Tun-режима.

Почему-то чат на сайте бинг не работает, если включать прокси через локалхост и порт, на котором неко сидит. Через тюн работает. На андроид приложение бинг работает, через этот же сервер с впн. Чат не работает ни в кром, ни в бинг. Дополнение SwitchyOmega не может загрузить результат чата? Хотел настроить и общаться иногда с ии, хотя он и тупой, зато поиск проще. Может, тогда весь трафик через впн пустить и фиг с ним и не думать об этом. Торрент всё портит.

Дополнение не загружает ничего, загружается браузер.
Если интересно копать глубже - открываем в браузере Developer Tools, там вкладку Network, и смотрим, какие запросы и почему именно падают.

Подозреваю, что возможно поможет что-то типа Prefer IPv4 в настройках резолвера на клиенте и/или на сервере.

Дя, всё так и есть... В девтул ничего не понятно. Но "Domain Strategy - prefer_ipv4" и "Server Address Strategy - prefer_ipv4" решили проблему. Эм... А оба пункта оставить?

Всё потому что сервер по 6 соединяется, а неко не хочет? Не понятно, а через в6 нельзя сидеть через впн? Вирт машина выдала в6 адрес тоже. Это нужно в марзбане заблокировать в6? Или это из-за отсутствия парковки в6 адреса? Ничего не знаю :( Вы очень помогли (умнее я не стал, правда).

А я г его знает почему именно так, честно говоря. Из-за отсутствия связности по IPv6 проблем быть не должно, все браузеры в этом случае обычно автоматически переключаются на IPv4. Проблема почему-то возникают наоборот от наличия IPv6 - гугл, например, таки юм клиента иногда тоже 403 ошибку отдает и никуда не пускает. Возможно как-то связанно с описанным в одном из вопросов этого FAQ нюансом со внутренними адресами при TUN-режиме, хз.

Благодарю ещё раз! Стало чуть комфортнее работать (хотя браузер почему-то лагает с прямой настройкой запросов к ру сайтам). Не умею карму делать тут, к сожалению. :з

Есть юзеры chatgpt? Поделитесь в ЛС на каких хостах вы арендуете VPS. У меня магия третьего курса хогвардса - хостер Aeza нидерланды.

  1. настроена 3x-ui панель и xtls-reality. с ПК пускает, со смартфона блочит

  2. настроен чистый xray-core сервер и xtls-reality. и на ПК и на смартфоне блочит.

шо-то я явно делаю не так :D если разберусь сам, напишу апдейт к комменту

Open AI по умолчанию запрещают доступ с non-residental IP-адресов (то есть 99.9% VPS-хостеров).

Некоторые упарываются и заворачивают выход с прокси на Cloudflare Warp :)

ага, я читал твой коммент в прошлых статьях об этом. Только ведь это не должно зависеть от того, как настроен прокси. Верно?)
на моём ВПС - с одной настройкой пускает, с другой не пускает. IP один и тот жеж стучится в дверь openai)

А ты мониторишь свой адрес через сайты who is и тому подобные, что ни пишут? Ты пользуешься платным чатом? Если 3,5, то браузера edge со встроенным чатом хватит для поиска инфы, помнит 30 запросов за отдельную сессию. Там и dalle есть. Попробуй firstbyte, но они написали, что если пущу трафик как в публичном vpn, то попросят. Поддержка отвечает быстро, но с намёком, что ищи сам справку, не маленький (на timeweb, например, всё объясняют). Ну, а тот же адрес можешь припарковать на cloudeflare. Лично я, поднял марзбан и всё работает (ничего в нём не понимаю).

Платным. https://browserleaks.com/ip и https://ip.gs/ ip4, ip6 указывают на мой ВПС. WebRTC отключен.

я хочу после фиксов имеющихся косяков, перейти на след уровень сложности и добавить запасной вариант CDN+WS по гайду ТСа. А для этого нужно оставаться на чистом Хрейе, не юзать панели)

В общем, firstbyte пускает на опенэйай без проблем (даже адрес припаркован у них). Насчёт утечек адресов не знал, поставил плагин на блок ip4, вроде, пока скрыл, но 6 светит, хотя в сетевом подключении отключил. Это возможно как-то скрыть? Благодарю.

А для этого нужно оставаться на чистом Хрейе, не юзать панели)

С панелью тоже можно, но с консолькой и ручной настройкой Nginx все равно придется попердолиться.

Некоторые упарываются и заворачивают выход с прокси на Cloudflare Warp :)

Конструкция не демаскирует xtls-reality?

Клиент <xtls-reality> Сервер <freedom> Интернет

Клиент <xtls-reality> Сервер <warp> chatgpt site

Захотелось, нагуглировал пошагово для хомяков как установить варп по офицальному гайду CF

на мою Ubuntu

# Добавить cloudflare gpg key

$ curl https://pkg.cloudflareclient.com/pubkey.gpg | sudo gpg --yes --dearmor --output /usr/share/keyrings/cloudflare-warp-archive-keyring.gpg

#Добавить какоето неведомое репо для шаманства.

$ echo "deb [arch=amd64 signed-by=/usr/share/keyrings/cloudflare-warp-archive-keyring.gpg] https://pkg.cloudflareclient.com/ $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/cloudflare-client.list

#Установить

$ sudo apt-get update && sudo apt-get install cloudflare-warp

$ warp-cli register

$ warp-cli set-mode proxy

$ warp-cli set-proxy-port 42424

$ warp-cli connect

# потестить что получаем другое IP

$ url -4 ip.gs -x socks5://127.0.0.1:42424

В конфиг Хрея в outbound добавить новый канал "варп" и в маршрутиризации новое правило, что бы разнюхивал трафик чатжпт и посылал в варп:

"outbounds": [
...

{
"tag": "WARP",
"protocol": "socks",
"settings": {
"servers": [ {
"address": "127.0.0.1",
"port": 42424 } ] }
} ],

...

"routing": {

...
"rules": [
{
"type": "field",
"outboundTag": "WARP",
"domain": ["geosite:openai"]
} ]

},

upd: с первой попытке сработало. Теперь и на ПК, и на телефоне ChatGPT работает.

@MiraclePtrВарп конструкция поверх реалити не демаскирует?

Не демаскирует, все ок.

Подскажите пожалуйста, планирую подключить к своему серверу не менее 50 человек, в предыдущем посте про настройку VLESS+Reality, Вы указывали на то, что необходимо указывать именно 443 порт. Полагаю один порт не выдержит поток 50 пользователей, будет ли палится сервер, если сажать пользователей на рандомные порты по протоколу VLESS+reality?

Нет такого что "один порт не выдержит поток пользователей", через один порт могут проходить тысячи соединений, никаких проблем не будет.

Суть Reality в том, что ваш прокси маскируется под популярный веб-сайт с HTTPS. К сайтам с HTTPS всегда подключение идет на 443 порт, и у вас должно быть так же. Если вы посадите людей на кучу разных портов (на каждом из которых будет отвечать HTTPS-сервер), то это наоборот будет очень подозрительно. А когда 50 человек подключаются к одному 443 порту, то это наоборот выглядит естественно - разные люди посещают популярный сайт.

Здравствуйте. Вопрос от полного нуба по X-UI. У меня есть VPS, на котором раньше стоял X-UI на порту 443 и работал без проблем. В какой-то момент хостинг переехал в другую страну и поменял мне доступные порты. Я установил на него через скрипт X-UI, настроил по вашей инструкции "Inbounds" также на 443, но когда я подключаюсь, мне пишет "В соединении отказано". Тогда я поменял в настройках порт на один из доступных мне, к примеру 1700 и у меня заработало. Скажите, насколько это критично?

Или может есть решение проблемы с 443? Мне кажется странным, что провайдер заблочил этот порт, хоть я в этом ничего толком не понимаю. Сама убунту у меня голая, стоит только X-UI. Сори за тупой вопрос, только учусь, пытаюсь разобраться.

Вообще это очень странно. Хостер ни при каких обстоятельствах не должен блочить 443 порт - это стандартный порт веб-серверов.

Начать можно с команды "netstat -nlp", чтобы убедиться, что никакой другой процесс не занимает порт, и с просмотра правил фаервола (в зависимости от вашего дистрибутива Linux на сервере), чтобы он не был закрыт на фаерволе.

Если с этим все нормально - то долбать саппорт хостера с вопросом "какого хрена?2.

Единственное исключение - существуют low-end NAT-VPS хостеры, когда на одном IP-адресе сидят сразу сотни клиентов, а доступ к серверам делается через проброс портов. Но и в этом случае обычно можно настроить SNI-прокси, чтобы в зависимости от домена в запросе подключение передавалось на ваш сервер, и еще часто они имеют IPv6, и можно настроить проксирование через CDN (но это не так-то просто и нужен домен, см. предыдущие статьи).

Давно мучает вопрос: почему так редко пишут про ipv6 в контексте обхода блокировок? В теории это как минимум даёт шанс обойти попадание конкретного VPS в блэклист по ipv4, потому что сейчас хостеры обычно выдают ipv4+ipv6, и ipv6 в такой ситуации оказывается незасвеченным. У большинства интернет-провайдеров в РФ ipv6 вроде бы тоже давно работает, хоть и отключен по умолчанию.

Есть какие-то подводные камни?

Да там писать нечего потому что. На ТСПУ блокировки для IPv6 работают точно так же, как и для IPv4, времена когда блочили только IPv4 забывая про IPv6 давно прошли. С поддержкой IPv6 у российских провайдеров гораздо хуже, чем хотелось бы. А когда использование IPv6 станет массовым, будут банить не точечно адреса, а сразу /64 или даже /48 подсеть.

подскажите пожалуйста, как пустить open vpn через Shadowsocks на примере панели 3x-ui. я понимаю что там можно создать протокол socks, но это не совсем то что нужно, хотелось бы пустить именно через плагин Shadowsocks с плагином шифрования 2022. или я фигню сморозил? прошу сильно не пинать тапками))

В панели настраиваете подключение Shadowsocks с шифрами 2022.

На клиенте настраиваете в качестве outbound подключение Shadowsocks, а в качестве inbound - SOCKS (обычно оно так и бывает всегда), и потом этот SOCKS на локалхосте указываете в конфиге OpenVPN как прокси.

Всё.

Привет!
я использую Shadowrocket на iOS/iPadOS/MacOS (M1). у меня 2 вопроса.


1. подскажите, плз, где что надо (и можно ли) прописать в Shadowrocket, чтобы исключить некоторые приложения из работы через прокси? например, необходимы приложения, которые работают только для России - окко, кинопоиск..
Пробовала прописывать bundle id приложения в Config/Rule (Domain-Suffix) и пускать его через Direct, но не особо что получилось. может, есть какой-то способ? хотя, окко заработало, но как-то не понятно. может, надо время.. потому что, сразу, когда настраивала - не работало. а через 2-3 попробовала - вроде, работает (еще потестирую).


2. у меня через NextDNS прописаны белые/черные списки сервисов. когда запускаю Shadowrocket работа через клиент NextDNS блокируется и, естественно, во время работы через прокси, у меня DNS не отрабатывает по спискам. в конфиге в General/DNS Override прописала DNS от NextDNS - это работает, но только для мобильной сети. а от провайдера - не работает. где что можно изменить, чтобы с интернетом от провайдера тоже работало?
спасибо!

Зайдите в настройки конфигурационного файла: Config - default.conf. Долгий тап по файлу и выбираете Edit Plain Text. Удаляете все оттуда и вставляете этот код:

# Shadowrocket: 2023-11-20 14:01:58
[General]
bypass-system = true
skip-proxy = 192.168.0.0/16,10.0.0.0/8,172.16.0.0/12,localhost,*.local,captive.apple.com
tun-excluded-routes = 10.0.0.0/8, 100.64.0.0/10, 127.0.0.0/8, 169.254.0.0/16, 172.16.0.0/12, 192.0.0.0/24, 192.0.2.0/24, 192.88.99.0/24, 192.168.0.0/16, 198.51.100.0/24, 203.0.113.0/24, 224.0.0.0/4, 255.255.255.255/32, 239.255.255.250/32
dns-server = 8.8.8.8,8.8.4.4
fallback-dns-server = 
ipv6 = false
prefer-ipv6 = false
dns-fallback-system = false
dns-direct-system = false
icmp-auto-reply = true
always-reject-url-rewrite = false
private-ip-answer = true
# direct domain fail to resolve use proxy rule
dns-direct-fallback-proxy = true
# The fallback behavior when UDP traffic matches a policy that doesn't support the UDP relay. Possible values: DIRECT, REJECT.
udp-policy-not-supported-behaviour = REJECT

[Rule]
RULE-SET,https://raw.githubusercontent.com/blackmatrix7/ios_rule_script/master/rule/Shadowrocket/Whatsapp/Whatsapp.list,PROXY
RULE-SET,https://raw.githubusercontent.com/blackmatrix7/ios_rule_script/master/rule/Shadowrocket/Telegram/Telegram.list,DIRECT
RULE-SET,https://raw.githubusercontent.com/blackmatrix7/ios_rule_script/master/rule/Shadowrocket/VK/VK.list,DIRECT
RULE-SET,https://raw.githubusercontent.com/blackmatrix7/ios_rule_script/master/rule/Shadowrocket/Yandex/Yandex.list,DIRECT
RULE-SET,https://raw.githubusercontent.com/blackmatrix7/ios_rule_script/master/rule/Shadowrocket/Google/Google.list,DIRECT
RULE-SET,https://raw.githubusercontent.com/blackmatrix7/ios_rule_script/master/rule/Shadowrocket/YouTube/YouTube.list,DIRECT
DOMAIN-SUFFIX,xn--80aswg,DIRECT
DOMAIN-SUFFIX,xn--c1avg,DIRECT
DOMAIN-SUFFIX,xn--80asehdb,DIRECT
DOMAIN-SUFFIX,xn--p1acf,DIRECT
DOMAIN-SUFFIX,xn--p1ai,DIRECT
DOMAIN-SUFFIX,su,DIRECT
DOMAIN-SUFFIX,ru,DIRECT
GEOIP,RU,DIRECT
# LAN
IP-CIDR,192.168.0.0/16,DIRECT
IP-CIDR,10.0.0.0/8,DIRECT
IP-CIDR,172.16.0.0/12,DIRECT
IP-CIDR,127.0.0.0/8,DIRECT
# Final
FINAL,PROXY

[Host]
localhost = 127.0.0.1

Сохраняете, затем включаете роутинг: Home - Global Routing - Config.

PS: в моем конфиге проксируется все кроме:

.ru доменов;

.su доменов;

доменов типа .рф, .сайт, .онлайн и т.д.;

RU сайтов по geoip;

сервисов: Google, Yandex, WhatsApp, Telegram, VK, YouTube

Спасибо за ответ!
но в перечисленных данных о том, что мимо проксирования вижу только сайты и сервисы.
Меня же конкретно интересует как можно исключить разные приложения, установленные на iOS из проксирования. в моем примере - это кинопоиск, окко.. в общем, любое, какое понадобится.


У вас в кофниге прописаны правила типа такого:
RULE-SET,https://raw.githubusercontent.com/blackmatrix7/ios_rule_script/master/rule/Shadowrocket/YouTube/YouTube.list,DIRECT

это установленное приложение YouTube исключает из проксирования или когда через браузер заходишь на YouTube? если приложение - можно таким же образом прописать правила для других приложений?

Ну и хотелось бы не тупо скопировать, а понять что делаю, чтобы, при необходимости можно было применить правила и для других нужных сервисов.)

Исключать приложения на ios нельзя (на android можно). Есть в shadowrocket еще возможность по user-agent настраивать правила (поможет для приложений).

Здесь вам надо понимать суть правил маршрутизации - любой ресурс/сервис/приложение в конечном итоге ссылается на определенные домены/ip. Поэтому, например, если вы настроите блок для youtube.com - то ни в приложении, ни в браузере вы доступ к нему не получите (только надо учитывать, что у крупных сервисов могут использоваться десятки или сотни ip/доменов на которых работают сервисы и их части. Например: youtubego.in, youtubei.googleapis.com, youtubekids.com, и т.д.)

Для иви, кинопоиска и прочего - ищите списки доменов/ip и добавляйте в shadowrocket (как в моем примере можно). Но вы так же должны понимать, что настройка директа .ru доменов и geoip:ru - позволит вам заходить практически на любой российский сайт/сервис/приложение без проблем. Если хотите только эти конкретные сервисы настроить - опять же, ищите листы с их доменами/ip и добавляйте в конфиг

Да, спасибо! как исключать сайты я в курсе. с правилом выше - тоже разобралась откуда что и зачем.)
И исключить приложение окко из проксирования у меня все ж получилось (спасибо ChatGPT - подтолкнул в какую сторону копать)). теперь при включении ракеты запускаются и спортивные трансляции, и просмотр видео. только надо понять какое из правил сработало. а то пока перебирала правила и получая отрицательный ответ, психанула и прописала их все скопом.:)
Попробую ещё с кинописком. и если получится, то можно уже будет сохранить как схему для обхода проксирования приложений.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Публикации

Читают сейчас

Истории

Идём на «Импульс Т1» по дороге из жёлтого кирпича
Как стать супергероем
Рейтинг IT-брендов работодателей 2023
Активность найма в 3 квартале 2023
Топ-7 годных статей из блогов компаний
Сколько тратят в IT: сеньор бэкендер
Перевернуть календарь и добавить событие

Работа